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ABSTRACT 


The U.S. Navy is interested in acquiring systems that promote the use of Services- 
oriented Architecture (SOA) and Open Architecture (OA) in Integrated Warfare Systems 
(IWS). The number of systems required to share data and provide reliable information in 
weapons systems is growing. Many systems, systems-of-systems and families of systems 
with different software architectures are acquired and often have difficulty operating 
together, which causes delays, increases costs, and limits re-use. Intelligent adoption of 
SOA and OA may help solve integration and reuse issues in current and future 
acquisition programs. The commercial market is successfully beginning to implement 
SOA and OA in their processes and may provide examples of best practices that can be 
applied to the Defense Acquisition System. The goal of this thesis is to explore the 
feasibility of implementing SOA and OA into the Defense Acquisition System. Adoption 
of SOA and OA practices is not expected to completely alter the current Defense 
Acquisition System; instead, it is intended to alleviate some of its constraints. This thesis 
will focus on utilizing SOA and OA in IWS, how SOA and OA principles relate, and the 


effects they will have on the Defense Acquisition System’s organizations and processes. 
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I. INTRODUCTION 


A. PURPOSE 


The purpose of this thesis is to analyze whether the Defense Acquisition System 
needs to be altered to take advantage of the implementation of Services-oriented 
Architecture (SOA) and Open Architecture (OA) principles into the acquisition of 
Integrated Warfare Systems (IWS). To accomplish this, the researchers will examine 
SOA and OA principles, processes and objectives; the Defense Acquisition System and 
the acquisition lifecycle; and the best practices of an emerging Naval acquisition program 
and its SOA implementation. The objective of this thesis is to discuss and generalize 
from the analysis any necessary realignment of the Defense Acquisition System and the 
acquisition lifecycle to allow new technology acquisition in military organizations that 


will benefit future [WS programs. 
B. BACKGROUND 


The United States Navy is attempting to restructure its defense enterprise in a 
manner more suitable to the current threat environment and evolving future threats. The 
Navy is trying to furnish the warfighter with the appropriate tools to defend against 
emerging threats. Over the last few decades, the Navy, along with the rest of the 
Department of Defense (DoD), has increasingly integrated itself by developing joint 
warfighting concepts, organizations, training and operations. However, updates to the 
Navy and the DoD acquisition policies, processes and practices have lagged behind, 
which has impeded the integration effort. Recent experiences have demonstrated the 
need for the Navy and the DoD to integrate their acquisition policies, processes and 
practices in order to foster joint acquisition solutions for the warfighting needs of 


tomorrow. 


The Congressional Budget Office has estimated an $895 billion decrease in 
defense spending between 2005 and 2014 (PEO-IWS 7.0 & the OA Enterprise Team, 


2007, p. 8). As competition for acquisition dollars becomes increasingly strenuous, the 
1 


Navy is challenged with difficult budget decisions. With inflexible acquisition strategies, 
the Navy has become locked into single systems and vendors that limit the options for 
competition and innovation. The Navy has acquired systems that have performed their 
functions and tasks exceedingly well; however, the Navy’s vertical “stove-piped” combat 
systems tend to be localized, preventing the sharing of information and technology across 
the different combat system programs. Acquiring combat systems using legacy processes 
and principles leads to the acquisition of combat systems that have duplicative 
capabilities, yet are incompatible and not interoperable. Each combat system is unique to 
the platform for which it was designed. These vertical “stove-piped” combat systems, the 
policies, processes, and practices, along with the information technology (IT) designed to 
implement these systems have become an increasingly tighter constraint within the 
acquisition process. The Navy has taken steps to diminish the utilization of vertical 
“stove-piped” combat systems infrastructure and to shift to a more dynamic, horizontal 


combat systems infrastructure that takes advantage of advances in IT. 


The Navy is continually seeking new ways to develop, field and support its 
sophisticated combat systems in order to meet the future needs of the warfighter. In order 
to keep up with advances in technology, the Navy has transitioned from the traditional 
detailed MILSPEC development model to an approach that stresses open systems and the 
use of commercial standards and commercial off-the-shelf (COTS) hardware and 
software. The United States Navy is becoming increasingly interested in the acquisition 
of IWS that utilizes Open Architecture (OA). Open Architecture is a confluence of 
business and technical principles that, when correctly applied, yields modular, 
interoperable systems that employs widely accepted standards and published interfaces 
that lead to options for greater competition and inclusion of innovators (Navy Office of 


Information, 2006). 


An OA approach combines business and technical principles and practices that, 
taken to their logical conclusion, will change the acquisition paradigm but will not 
provide the Navy with solutions for solving the vertical to horizontal acquisition process. 
Joseph Uchytil’s Naval Postgraduate School thesis, Assessing the Operational Value of 
Situational Awareness of AEGIS and Ship Self-Defense System (SSDS) Platforms through 
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the Application of the Knowledge Value Added (KVA) Methodology, demonstrated the 
operational benefits and the Return on Investment (ROD) that could be realized through 
the application of an OA approach to systems design. Jameson R. Adler and Jennifer L. 
Ahart’s Naval Postgraduate School thesis, AEGIS Platforms: Using KVA Analysis to 
Assess Open Architecture in Sustaining Engineering, builds on Uchytil’s research by 
assessing the impact of implementing an OA development and acquisition approach to 
Sustained Engineering (SE) in IWS. Adler and Ahart demonstrated the benefits of OA 
and the ROI gained from implementing OA within SE, and they laid the foundation for 
the possible implementation of Services-oriented Architecture to eliminate organizational 


“stove-pipes” within the acquisition process. 


SOA development practices may provide the framework and the components to 
more efficiently develop architectures more conducive to future [WS. “SOA establishes 
an architectural model that aims to enhance the efficiency, agility, and productivity of an 
enterprise by positioning services as the primary means through which solution logic is 
represented in support of the realization of strategic goals associated with service- 
oriented computing” (Erl, 2008a, p. 38). SOA is not an entirely new IT paradigm; it 
merely approaches silo-based problems by building on previously proven development 
processes by introducing agnostic services, which allows for increased horizontal 
integration (p. 84). This thesis will build on the past work of Uchytil, Adler and Ahart by 
examining the implications of implementing SOA and OA within the Defense 


Acquisition System. 


Cc. RESEARCH OBJECTIVES 


The research conducted for this thesis encompasses several objectives. The first 
objective is to examine the relational architecture between SOA and OA systems. The 
second objective is to review the Defense Acquisition System to determine the feasibility 
of moving toward SOA and OA systems. The third research objective is to identify any 
possible constraints within the Defense Acquisition System that may prevent an SOA and 
OA approach in IWS. The fourth research objective is to examine best practices of Naval 


acquisition programs that are currently incorporating SOA and OA into their acquisition 
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processes. The fifth and final objective of the research is to examine potential re- 
alignments of the Defense Acquisition System that will allow new technology acquisition 


in military organizations. 
D. RESEARCH QUESTIONS 


This thesis attempts to provide constructive, educational and useful answers to 
Navy IT decision-makers for three questions, as well as providing recommendations 
concerning the direction in which the Navy and the DoD may wish to proceed in the 
future when acquiring systems that benefit horizontally across multiple acquisition 
programs. 


e Does the Defense Acquisition System need to be altered to take advantage of SOA 
and OA implementation into the acquisition lifecycle? 


e Do current Navy OA policies and SOA practices provide the necessary 
interoperability requirements for future [WS? 


e What benefits might SOA and OA provide to [WS? 
E. METHODOLOGY 


In order to provide a better understanding of SOA and OA and their relationships, 
this research paper first provides a general overview of SOA and OA concepts. In order 
to accomplish this, the authors will conduct a literature review of SOA and OA. They 
will then examine the Defense Acquisition System by conducting a literature review of 
DoD and Naval acquisition policies and initiatives. Next, there will be an analysis of 
organizational utilization of SOA and OA and a development of a mini case study based 
on current SOA implementation for the Consolidated Afloat Networks and Enterprise 
Services (CANES) project. The end result of this thesis will be to develop 
recommendations based on findings in the literature reviews and analysis of the mini case 


study. 


F. SCOPE 


This research will address the principles, processes and objectives of SOA and 
OA frameworks, as well as their relationships and how they can be integrated into the 
Defense Acquisition System. It will include a literature review of SOA and OA, in 
addition to providing an overview of the current Defense Acquisition System. The SOA 
development process for CANES will be examined, with concentration on the planning 


and implementation of the core services. 
G. THESIS ORGANIZATION 


Chapter I has provided a general overview of the problem, explained the research 
objectives, introduced the thesis questions, and defined the methodology and scope. 
Chapter II will provide research and background information on Services-oriented 
Architectures, Open Architecture and the relationship between them. Chapter III will 
consist of a review and evaluation of the current Defense Acquisition System, SOA and 
OA requirements, and an analysis of a transition from the vertical “stove-piped” 
acquisition process to a horizontal acquisition process. Chapter IV will provide a 
discussion and analysis of a current Navy acquisition program incorporating SOA and 
OA into its acquisition process. Chapter V_ will contain conclusions and 


recommendations as well as topics for future research. 
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I. LITERATURE REVIEW: SERVICES-ORIENTED 
ARCHITECTURE AND OPEN ARCHITECTURE 


A. SERVICES-ORIENTED ARCHITECTURE (SOA) 


This section provides a definition of Services-oriented Architecture (SOA), 
discusses some SOA influences, outlines SOA concepts and principles, and discusses 


some benefits and challenges of SOA. 
i Definition 


Services-oriented Architecture (SOA) is defined differently by many 
organizations. The absence of a concrete definition may allow organizations to more 
easily adapt an SOA to their current business processes. Simply defined, SOA is “an 
architecture for a system or application that is built using a set of services” (O’Brien, 


Bass, & Merson, 2005, p. 3). Examples of varying SOA definitions are listed below. 


® An SOA is “a set of components which can be invoked, and whose 
interface descriptions can be published and discovered.” (W3C, 
2004) 

e "The SOA models the business as a collection of self-contained 


services that are available across the enterprise that can be evoked 
through standard protocols both internally and externally." 
(McComb as cited by Mimoso, 2004) 


° "Service Oriented Architecture (SOA) is an approach to the 
development of loosely coupled, protocol-independent distributed 
applications composed from well-defined, self-contained software 
resources accessible as Services across the extended enterprise in a 
standardized way, enhancing re-usability and interoperability." 
(Gupta as cited by Mimoso, 2004) 


e "SOA is an approach to building software applications as 
collections of autonomous services that interact without regard to 
each other's platform, data structures, or internal algorithms." 
(Champion as cited by Mimoso, 2004) 


Although the definition of SOA varies in the information technology industry, 


some basic and useful concepts may be utilized to improve processes. Re-use, 
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interoperability, availability, and standard interface protocols across an entire enterprise 
are key business concepts that may prove beneficial in United States Naval platforms. 
Many organizations already employing an SOA are streamlining their processes to reduce 


redundancy, thereby reducing costs. 


2. Service Definition 


“A service is an implementation of a well-defined piece of business functionality, 
with a published interface that is discoverable and can be used by service consumers 
when building different applications and business processes” (O’Brien et al., 2005, p. 1). 
This definition gives a broad overview of a service but can be built upon to better 
understand what services can do for an organization. Services are also relatively isolated 
from other services, and they also can provide a “collection of capabilities,” not just a 
single capability. Capabilities with a common function may be contained in a single 
service, such as a shipment service. The shipment service would incorporate the get, add, 
and report capabilities (Erl, 2008a, pp. 69-70). Organizations must understand the 
capabilities of each service composed in their SOA to reduce redundancy and to promote 


re-use and interoperability. 


3. SOA Influences 


“While reuse, especially over time, can be one of the most rewarding parts of 
investing in SOA, it is not the sole primary benefit. Perhaps even more fundamental to 
service-orientation than promoting reuse is fostering interoperability” (Erl, 2008a, p. 90). 
SOA is not a design paradigm that materialized out of thin air; rather, it is influenced by 
previous design paradigms and technologies that leverage the best practices from each to 
provide greater interoperability and increase the re-use potential. Figure 1 depicts the 
design paradigms and technologies that represent the primary influences of service- 
orientation. SOA draws successful and proven approaches from these past paradigms 
and couples them with emerging IT principles. SOA remains in a state of evolution and 


continues to be influenced by the newest technology innovations. 





Figure 1. Primary Influences of Service-orientation from 
(Erl, 2008a, p. 97) 


4. Re-use 


Re-use provides advantages by allowing the same or similar process use in 
various architectures, systems, or applications. The use of previously proven concepts 
reduces development and implementation times. Additionally, re-use provides the ability 
to use the same service among platforms that have overlapping missions. Utilizing 
agnostic services across multiple platforms reduces system complexity and future 


redesign costs. 


Re-use is an enabler to service composition. As re-use potential increases, so do 
the available compositions. Services should not be developed for particular 
compositions; rather, they should be developed to operate in numerous compositions. As 
service inventories for Naval Integrated Warfare Systems (IWS) mature, the desire is to 
allow multiple applications on multiple platforms to use common services. Services 
designed for IWS should be agnostic enough to operate across multiple systems. 
Correctly designed services will provide the necessary compositions required for 


evolving Navy IWS requirements. 


Historically, re-use has been highly desired in the software industry but often 
difficult to achieve. Typically, “reuse increases the complexity, cost, effort, and time to 
build software” (Erl, 2008a, p. 257). Some reasons these attributes exist are that software 
designers are designing applications to fulfill requirements for a specific process or only 
to solve immediate problems. Return on investment (ROI) is easier to calculate when 
using single purpose applications. Each application has measurable inputs and outputs 


that equate to an understandable ROI. “This type of reasoning is what has led to the 
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popularity of siloed application environments” (p. 257). The difficulty associated with 
calculating ROI of reusable services is more complex, and the benefits may not be 
realized at initial service implementation. As a service is re-used and new service 
compositions are formulated, the ROI will continue to increase, as illustrated in Figure 2. 


traditional 
unit of solution 


00 
qu 


Jelivery cost RO! 


Figure 2. Example of ROI for SOA Projects from (Erl, 2008a, p. 62) 


The re-use concept requires a shift from traditional system development and also 
requires stakeholders and architects to look horizontally across multiple systems and 


consider future requirements that may benefit from re-use. 


Many Naval systems are currently developed vertically or in “silos.” This has led 
to redundant applications and escalating costs. Re-use among IWS can alleviate long- 
term cost burdens and streamline systems. SOA provides design principles to guide 
Navy IWS toward more agile systems that provide better interoperability and future cost 
reductions. There are differing viewpoints on how to calculate ROI for SOA, which will 


be discussed later in this chapter. 
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Ae Interoperability 


Common services provide seamless interaction with new and legacy systems, 
regardless of platform specific characteristics. SOA uses interfaces to allow data sharing 
between systems that were unable to communicate in the past. As legacy systems are 
encapsulated and enter into the SOA-based framework, interoperability becomes more 
transparent. Reuse is directly related to interoperability. As service reuse increases, 


interoperability increases, providing a less burdensome IT structure. 
6. Availability 


Availability is the rate at which services are accessible. SOA provides the 
advantage of constant availability since single components are responsible for 
compartmentalized data. Service availability is crucial in Naval Integrated Warfare 
Systems. With multiple entities relying upon a given service, degraded availability may 
occur. Complete loss of a high-demand service affects all applications subscribing to that 
service. Backup services should be considered when designing an SOA around critical 


systems. 
7. Interface 


Interface protocols are becoming standard across industries. The Navy can use 
proven standard interface protocols to integrate legacy systems into services-oriented 
systems. Common interface protocols allow services to provide data to different 
platforms, thereby increasing an enterprise’s agility (Gorton, 2006, p. 152). “Agility, on 
an organizational level refers to the efficiency with which an organization can respond to 
change” (Erl, 2008a, p. 63). Agility refers to how quickly services in an organization can 
be composed and has nothing to do with how quickly services can be developed. As 
agility increases, interoperability increases due to standard interface protocols and the 


time to change system components is reduced. 
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Services are linked by service contracts. Service contracts allow services to 
communicate and “establishes the terms of engagement, providing technical constraints 
and requirements as well as any semantic information the service owner wishes to make 
public” (p. 126). Service contracts allow the owner to permit customers to see only the 
logic required to establish use, while allowing a service to remain abstract enough to 
reduce service dependency. Service contracts should address how a service is used and 


also address the composability of that service. 
8. Service Location 


Once services are developed and deemed essential components for a given 
architecture, service location must be addressed. Some systems may require services 
located in closed environments, such as aboard ships—where only applications internally 
related have access to the services—while other systems may subscribe to services 


external to their environment. 


In closed systems with known services and service locations, each service is 
accessed by one or more applications but with limits on the number of applications 


subscribing to each service. 


Open systems that subscribe to external services need the ability to process 
requests from large numbers of subscribers. Concerns for excessive latency, varying 


application interfaces, and service availability may decrease service reliability. 


Before developing any SOA, the stakeholders must determine which services are 
required, their locations, how they are accessed, and which services are mission-critical. 
Ideally, a system is built from existing services to easily develop an SOA that provides 
desired system functions. Required services that do not exist must be developed to 
provide desired functions and should be agnostic, allowing subscription from other 


systems and applications. Service location limits re-use and accessibility. 


Different SOAs use varying applications and require interface protocols for 
service subscription and the service contracts they use. Determining service type and 


location determines the application interface. 
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Latency and availability issues in mission-critical systems require risk-mitigation 
solutions. Latency problems surface as subscription increases for a given service. 
Increased latency may lead to unacceptable reduced availability in mission-critical 
systems. Mission-critical systems require additional services or duplicate services to 


mitigate risk if runtime issues cannot be overcome. 
9. Loose Coupling 


Loose coupling refers to the dependency of services upon each other. An SOA 
design goal is to reduce the dependency between services, while still providing 
interoperability within a system. It is desirable to have just enough coupling to maintain 
interoperability, while reducing dependency. As the dependency loosens, re-use potential 
is improved, which allows service design more flexibility. Although loose coupling is 
desired in an SOA, interoperability—as stated earlier—has greater importance. Services 
should only have reduced dependency to a degree that they still allow interoperability 


between multiple services and across multiple applications. 
10. SOA Design Standards 


Design standards are central to SOA development. Although design standards in 
the information technology environment often require significant establishment time, 
they also provide for more efficient designs. Design standards are not necessarily new 
information technology standards; they can be data standards or interface standards that 
currently exist. These standards will allow an organization to better understand the 


architecture being pursued and aid in understanding the system constraints. 
11. Quality of Service (QoS) 


Quality of Service (QoS) refers to the reliability of data flows in a network. QoS 
provides different priority levels to data flows and an assurance that data loss will be 
reduced or prevented. Networks with limited bandwidth and critical systems may rely on 
higher QoS levels for increased reliability. Critical data is given priority over less 


important data using QoS protocols. As critical flows increase, data flow queue 
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management tools limit lower priority data flows to ensure that higher priority data is 
transmitted with greater reliability. QoS tools are intended to improve reliability of data 
flows within a network, but they do not solve bandwidth problems in highly congested 
networks. The Navy’s IWS have many components with critical data flows and will 


require QoS tools to prioritize network traffic. 
12. _—_‘ Phased Transition 


An organization should develop detailed plans using an architecture evaluation 
method prior to implementation of a complete SOA. Rather than attempting to transition 
an enterprise from legacy systems to a complete SOA all at once, incremental 
implementation is recommended. Architectural evaluations will mitigate risks for each 
planned increment and alleviate potential re-work. Incremental implementation also 
allows an organization time to adjust to changes and provides an environment fostering 
adaptation and acceptance as personnel become more familiar with new systems. Users 
may have difficultly adapting to entirely new systems and may resist an SOA if they are 
not given time to understand the new systems. To mitigate change management risks, a 


phased transition is recommended (Erl, 2008a, p. 87). 
13. Governance 


Governance refers to the application of processes utilized throughout an 
organization when developing an SOA. These processes govern how SOAs are designed, 
developed, implemented, and maintained, which ensures conformity to the guiding 
architectural principles and regulations established by the organization. “Governance 
represents the responsibility of administering, maintaining, and evolving what is 


delivered by SOA projects” (Erl, 2008b, p. 97). 
14. ROI 


As stated earlier in this chapter, there are differing viewpoints on how to calculate 
return on investment (ROD for SOA. Experts argue the feasibility of calculating ROI for 
SOA. 
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What makes calculating the ROI of SOA even more challenging is that 
architecture, by itself, doesn’t offer specific features that companies can 
readily identify with some particular return. After all, architecture is an 
investment that companies must make well in advance of any return, and 
must continue to make over the lifetime of their SOA implementations. 
(Schmelzer, 2005) 


Some experts believe ROI for SOA does not provide a true measure of 
benefits since the calculated ROI is based upon components that make up 
the system and these measures do not capture the benefits of the entire 
solution. SOA is a set of best practices, a philosophy, and a drive toward 
business transformation. SOA, for the most part, is intangible, with long- 
term results to the business. (McKendrick, 2007) 


The larger issue is that SOA, at the end of the day, is a systemic change in 
the way organizations approach enterprise architecture. Thus, the benefits 
will only be understood when the architecture has undergone that change. 
(Linthicum, 2007) 


Although some experts do not believe there is real value in calculating ROI of an 
SOA, others believe it is required and are using innovative methods to calculate ROI for 
SOA. “Some measure of ROI is nearly always used as a justification for major 
technology investments within large enterprises” (Gabhart, 2007, p. 1). Gabhart divides 
SOA ROI calculations into three quantifiable benefits of SOA: “Tactical ROI as a result 
of standards-based service oriented integration, Operational ROI based on service and 


process reuse, and Strategic ROI due to business and technology agility” (p. 2). 


Tactical ROI focuses on reducing redundancy and other initial cost reductions to 
provide justification for initiating an SOA. The four steps listed below describe the 
method for calculating tactical ROI. 

e Compute the savings realized due to reduced middleware licensing costs. 

e Compute the savings afforded due to reduced development time. 

e Project savings due to reduced maintenance costs. 


e Add the results of steps 1-3 together and fold that into whatever ROI formula 
your organization uses (i.e. net gain divided by investment). (Gabhart, 2007, 


p. 2) 
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As previously stated, tactical ROI is just an initial figure for SOA justification. 
Operational and strategic ROI must be analyzed to provide more accurate estimations of 


an SOA’s value. 


Operational ROI provides information for “the short to medium time frame,” by 
analyzing the re-use of services. Two methods for calculating operational ROI for SOA 
are the iterative re-use model and the calculated re-use model. When using the iterative 
re-use model, the “investment return is measured based on the number of times a service 
or process is reused rather than an arbitrary time frame” (Gabhart, 2007, p. 3). 
Development of reusable components may initially cost much greater than non-reusable 
components, but the cost savings are realized upon each successive re-use of a given 
service. The calculated re-use model is a “mathematical model [that] computes SOA 
value based upon a few key variables such as number of services available for reuse, 
degree of reuse, and service complexity” (p. 3). This method requires an organization to 
compare current non-SOA development component costs to those that are developed for 


re-use in an SOA. 


Strategic ROI should be calculated to provide a complete analysis of the long- 


term benefits gained by implementing an SOA. 


Strategic ROI is manifested though cost controls, risk mitigation, and new 
revenue generation as a result of agility...Strategic ROI is the ultimate 
expression of what SOA is all about. It’s about making a strategic 
investment in an agile enterprise infrastructure and at the same time 
aligning the business and technology sides of the organization to work 
toward common, shared objectives. (Gabhart, 2007, p. 4) 


Listed below are guidelines for calculating strategic ROI. It is important to 
understand that strategic ROI is more an art than a science. 


e System development and maintenance costs saved due to the ability to 
modify information systems with little to no coding required (simply 
modify or rearrange the orchestration of several services). 


e Estimated legal costs and fines avoided due to faster and more reliable 
responsiveness to regulatory changes. 


e Revenue generated via the rapid creation of new services as well as the 
manipulation and reconfiguration of existing ones. 
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e Revenue generated due to ability to expose internal capabilities as 
consumable services by business partners and clients (this potentially 
generates completely new streams of income). (Gabhart, 2007, p. 4) 


Calculating ROI for an SOA is not a concept that gains consensus from all SOA 
experts, but as more organizations migrate to SOA, methods for ROI calculation are 
emerging. Gabhart’s method is only one recommendation for calculating the ROI for an 
SOA. Employing Gabhart’s method provides guidelines for initial ROI estimates as well 
as medium to long term ROI estimates. In the future, managers are not likely to proceed 


with any IT endeavor that lacks measures for providing a return on investment. 
15. SOA Benefits 


Silo-based systems make architectural evolution difficult due to multiple systems 
with independent architectures that are not compatible. The Navy currently acquires 
systems vertically (as separate acquisition processes). Service-orientation solves the 
evolution issues, since systems can be developed horizontally across many acquisition 
programs. Once horizontal development begins, all programs utilizing an SOA can begin 
development using a common framework and components, consequently, reducing 


design time, implementation time, and overall cost reduction. 


Service-orientation attempts to solve past problems by designing for the concepts 


listed below (Erl, 2008a, p. 81). 


e Increased consistency in how functionality and data is represented 

e Reduced dependencies between units of solution logic 

* Reduced awareness of underlying solution logic design and 
implementation detail 

e Increased opportunities to use a piece of solution logic for multiple 
purposes 

e Increased opportunities to combine units of solution logic into 


different configurations 


° Increased behavioral predictability 
e Increased availability and scalability 
e Increased awareness of available solution logic 


re. 


16. SOA Challenges 


Some challenges that SOA systems face are outlined below (Erl, 2008a, p. 85): 


Increased performance requirements: As multiple systems reuse a 
single service, system performance needs to increase to keep up 


with demand and prevent latency issues. Performance measures 
will need to be developed for each service based on intended 
usage. 


Reliability due to concurrent usage: A service may exhibit reduced 
reliability as more than one system is requiring that service’s 
functions at the same time. Controls to mitigate the risk of reduced 
reliability must be introduced for critical systems. 





Single point failure: As an increasing number of systems rely on 
one service for a particular function or process, failure of the 
service will impact every system relying upon that service. 
Governance may aid in mitigating this risk. Backup systems are 
not ideal, but should be considered for high-risk processes. 


Increased demand on hosting environments: As demand on 
hosting environments increases, runtimes may become excessive 


and lead to excessive latency issues. Hosting environments will 
need to be scalable to mitigate increased demand. Concurrent 
requests from multiple applications must be addressed to reduce 
latency issues as a Service processes these requests. 


Service contract versioning issues and redundant service contracts: 
Service contracts address how services will interface with various 


applications and describe their desired functionality. Versioning 
must be standardized to avoid confusion and redundant operations 
that may lead to increased runtime. Proper governance will reduce 
the likelihood of versioning issues and redundant service contracts. 


OPEN ARCHITECTURE (OA) 


This section defines Open Architecture (OA), introduces and defines Naval Open 


Architecture (NOA), outlines the NOA strategy and business model, and discusses how 


the Navy assesses the “openness” of its programs. 


1. Definition 


The concepts of open architecture (OA) have been around for years. Simply put, 


OA is an architecture that employs open standards for key interfaces within a system. 
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What this means is that the components of a system or a system-of-systems are easily 
interchangeable, simply plug and play. OA principles encompass both the business 
processes and technical practices that enable modular, interoperable systems that adhere 
to open standards. These principles apply to both the construction of a system and the 
management of its lifecycle. The fundamental drivers of OA are to reduce total 


ownership costs and time to deliver a system. The goals of OA are to 


e Increase Reuse 

® Increase Flexibility 

e Faster Time to Market 

e Reduce Costs 

e Leverage Competition 

e Improve Interoperability 


° Reduce Risk (Nelson, 2007, p. 8) 


OA principles are intended to support these goals and fundamental drivers by 
identifying the key business processes and technical practices that aid in the construction 


and deployment of OA systems. 
2. Naval Open Architecture (NOA) 


In the commercial environment, new technologies have driven the market to adapt 
to a modular open systems approach to developing new systems. This same environment 
has also affected the acquisition of National Security Systems (NSS) across the DoD. 
The Navy, having realized the impacts and opportunities associated with open 
architecture, has implemented its own open architecture policy. Naval Open Architecture 
(NOA) is an enterprise-wide, multi-faceted business and technical strategy for acquiring 
and maintaining NSS as interoperable systems that adopt and exploit open system design 


principles and architectures (PEO-IWS, 2007). 


The NOA website defines its open architecture as “a Navy initiative for a multi- 
faceted strategy providing a framework for developing joint interoperable systems that 
adapt and exploit open-system design principles and architectures” (DAU, 2006, p. 13). 
This framework includes a set of principles, processes, and best practices that: 
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e Provide more opportunities for competition and innovation 


e Rapidly field affordable, interoperable systems 


e Minimize total ownership cost 

® Optimize total system performance 

e Yield systems that are easily developed and upgradeable 
e Achieve component software reuse (p. 13) 


3. NOA Strategy 


In order to help implement its open architecture framework, the Navy has 
developed an overarching NOA strategy. This strategy includes a vision statement, 
principles, goals and supporting objectives. The NOA vision is to “transform our 
organization and culture and align our resources to adopt and institutionalize open 
architecture principles and processes throughout the naval community in order to deliver 


more warfighting capabilities to counter current and future threats” (PEO-IWS, 2007, p. 
1). 


In order to achieve the NOA vision, five underlying principles have been 


identified. These five principles are: 


1. Encourage competition and collaboration through the development of 
alternative solutions and sources. 


2. Build modular designs and disclose data to permit evolutionary designs, 
technology insertion, competitive innovation, and alternative competitive 
approaches from multiple qualified sources. 


3. Build interoperable joint warfighting applications and ensure secure 
information exchange using common services (e.g., common time 
reference), common warfighting applications (e.g., track manager) and 
information assurance as intrinsic design elements. 


4. Identify or develop reusable application software selected through open 
competition of “best of breed” candidates, reviewed by subject-matter- 
expert peers and based on data-driven analysis and experimentation to 
meet operational requirements. 


20 


5. Ensure lifecycle affordability including system design, development, 
delivery, and support while mitigating Commercial off-the-Shelf (COTS) 
obsolescence by exploiting the Rapid Capability Insertion 
Process/Advanced Processor Build methodology. (PEO-IWS, 2007, p. 2) 


In order to adhere to these five principles, the Navy has established several goals 
and supporting objectives. While the following goals define the direction for the Navy’s 
software architectures, the supporting objectives strengthen each goal by describing how 


they will be accomplished. The goals and their supporting objectives are outlined below. 
Goal 1: 


Change Naval processes and business practices to utilize open systems 
architectures in order to rapidly field affordable, interoperable systems. 


Supporting Objectives: 


1. Provide and refine policies, guidance and definitions required to 
establish a common approach for Naval OA. 


2. Support OPNAV in coordinating budget guidance across combat system 
and C4ISR communities, exploiting synergies across existing programs of 
record, to support Naval Power 21 priorities. 


3. Assist the Milestone Decision Authority, Program Manager, and 
Resource Sponsor in assessing program openness, where appropriate, to 
make informed OA investment decisions. 


4. Implement and refine OA Contract Guidance for use in applicable 
procurements tailored as necessary to meet domain-specific requirements. 


5. Facilitate cross-domain component reuse to reduce costs and enable 
more effective technology insertion. (PEO-IWS, 2007, pp. 2-3) 


Goal 2: 


Provide Naval OA systems engineering leadership to field common, 
interoperable capabilities more rapidly at reduced costs. 
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Supporting Objectives: 


1. Conduct Naval OA systems engineering experimentation to facilitate 
the fielding of interoperable capabilities and encourage collaboration. 


2. Oversee Naval OA implementation efforts ensuring standardized and 
disciplined processes are utilized across domains. 


3. Identify and foster "quick win" candidates and near-term proofs of 
concept for OPNAV to field additional capabilities at reduced costs. 


4. Ensure the Naval OA process remains relevant to S&T advancement. 


5. Work with the Test & Evaluation (T&E) community, academia, and 
industry partners to identify opportunities for reducing T&E expenses as a 
result of OA. (PEO-IWS, 2007, pp. 2-3) 


Goal 3: 


Change Navy and Marine Corps Cultures to Institutionalize OA 
Principles. 


Supporting Objectives: 


1. Increase awareness of Naval OA through the development of standard 
communication tools (i.e. presentations, papers, web content). 


2. Increase workforce skill sets through targeted training and ongoing 
research. 


3. Conduct Outreach to External Stakeholders to increase the awareness of 
the Naval OA initiative. (PEO-IWS, 2007, pp. 2-3) 


4. Open Architecture Enterprise Teams (OAET) 


To implement the Naval OA strategy, Navy leadership established a Naval Open 
Architecture Enterprise Team (OAET). The Program Executive Officer Integrated 
Warfare Systems (PEO-IWS) was assigned overall responsibility and authority for 
directing the NOA effort and was designated as the OAET lead. Representatives from 
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AIR, SURFACE, SUBS, SPACE, C4I and Marine Corps domains are incorporated into 
the OAET to ensure that NOA principles, guidelines, business practices, and technical 
solutions are utilized across the enterprise and within each domain. The OAET is 
responsible for developing an overarching OA acquisition and business strategy (Young, 


2004, August 5). 


5. NOA Business Model 


The Navy has developed an OA business model to help guide the acquisition 
process. The Navy’s OA business model focuses on several key principles, including the 
utilization of performance specifications; specialization at the module or component 
level; defining roles and responsibilities for component delivery, system integration and 
lifecycle support; and the criticality of a “spiral” or “build test build” process (DAU, 
2006, p. 3). Figure 3 illustrates the Navy’s OA business model. 
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Figure 2 for Warfare Systems of Systems 


Figure 3. OA Business Model from (DAU, 2006, p. 2) 


6. NOA Tools 


The OAET has developed an assessment model and an assessment tool to help 
program managers evaluate the “openness” of their respective program or system. The 
Open Architecture Assessment Model (OAAM) is a descriptor of the openness of a 
program or system. The OAAM was developed to provide program managers a means of 
describing the openness of their program or system. Program managers accomplish this 
by assessing their respective program or system and determining the “as-is” level of 
openness and the desired “to-be” level of openness. The OAAM provides a macro-level 
evaluation of the program or system and is not meant to provide improvements but rather 


to uncover alternatives for creating more openness. 
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The Open Architecture Assessment Tool (OAAT) provides two functions: 1) a 
descriptive measure of a program’s or system’s level of OA maturity and 2) a means by 
which a program manager can determine where his or her program stands with regards to 
what is possible (Shannon, 2006, October 19). The OAAT is an analytical tool that 
assesses the openness of a program or system based on business and technical interrelated 
questions. The OAAT implements the OAAM as a descriptor and provides a reproducible 


and more consistent method of evaluating a program or system. 


Employing the OAAM and OAAT is a continuous process that identifies a 
program’s or system’s current state of openness, desired state of openness, and the 
alternatives to progress from the current state to the desired state. As alternatives are 
examined, a business case is developed to determine the progression toward the desired 
state of openness. The OAAM and OAAT should be used during all phases of the 
acquisition process in order to continually assess and facilitate the OA maturity of a 


program or system. 


C. SOA AND OA RELATIONSHIP 


The previous sections discussed the background of SOA and OA. This section 
will discuss the relationship between SOA and OA. 


An SOA can be built using proprietary means; however, this type of SOA would 
not take full advantage of the strategic goals and benefits of utilizing an SOA. Therefore, 
to fulfill the SOA vision, an SOA should focus on exploiting open standards and OA 


principles. 


1. Strategic Goals and Benefits of SOA 


There are several strategic goals and benefits associated with an SOA. The 


strategic goals of an SOA are: 


e Increased Intrinsic Interoperability 
° Increased Federation 
® Increased Vendor Diversity Options 


e Increased Business and Technology Alignment (Erl, 2008b, p. 12) 
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The strategic goals of an SOA lead to the attainment of the strategic benefits, 
which are: 
e Increased ROI 
e Reduced IT Burden 
e Increased Organizational Agility (p. 12) 


The strategic goals and benefits of an SOA are long-term goals and are intended 
to improve the IT environment throughout the entire enterprise. These long-term 
strategic goals contrast the previously used tactical goals of traditional “stove-piped” 


applications that focused on meeting short-term requirements. 


Ze Applying Open Standards and OA Principles 


Employing open standards and applying OA principles to an SOA promote the 
strategic goals and benefits of the SOA. Applying OA principles increases the flexibility 
of software applications by utilizing standard interfaces that increase the interoperability 
of different systems. Open standards promote vendor diversification by abstracting 
proprietary implementation details, which allows vendors to easily integrate system 
components. As new technologies are developed, open standards and OA principles 
permit interfaces that are technologically neutral, which allows systems to be easily 


upgradeable and interchangeable. 


D. SUMMARY 


This chapter defined important terms, concepts and principles, and defined the 
relationship between SOA and OA. Services-Orientated Architecture and design is a 
relatively new and emerging paradigm that increases system interoperability. Experts’ 
definitions vary on what and how an SOA is designed and implemented, but most agree 
on core concepts. SOA increases interoperability across multiple systems that previously 
had very centralized processes. IWS can benefit from SOA as common services are used 
across multiple platforms. Reuse is another benefit SOA aspires to provide. As service 
re-use increases, IWS will be modified more easily and ROI will increase as redundant 


applications are replaced by composable service structures. SOA provides the benefit of 
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incremental implementation that reduces integration issues and allows organizations to 
adapt to an SOA over time. Challenges exist when implementing an SOA, but with 


proper planning and architectural evaluations many risks are mitigated. 


The Navy currently follows the DoD guidance requiring exploration of OA 
software systems. To further OA use within Naval systems, the Navy should begin to 
combine the use of OA with other emerging technologies such as SOA and services- 
oriented computing. The next chapter will examine the current Defense Acquisition 


System in order to help answer the first thesis question. 
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Hl. DEFENSE ACQUISITION SYSTEM 


A. INTRODUCTION 


The previous chapter provided some background information on the basic 
principles and concepts behind Services-oriented Architectures (SOA) and Open 
Architectures (OA), defined the relationship between them, and discussed some of the 
benefits of incorporating SOA and OA into IWS. This chapter will focus on the current 
Defense Acquisition System and will provide an explanation of how to incorporate SOA 
and OA into the acquisition process in order to provide an answer to the first thesis 
question: “Does the Defense Acquisition System need to be altered to take advantage of 


SOA and OA implementation into the acquisition lifecycle?” 


Within the Defense Acquisition System, there are three major decision-support 
systems utilized by defense leaders to enable proper decision-making concerning the 
acquisition of National Security Systems. These decision support systems include the 
Joint Capabilities Integration and Development System (JCIDS); the Defense Acquisition 
System; and the Planning, Programming, Budgeting and Execution System (PPBE). The 
incorporation of SOA and OA into IWS impacts each of these three decision support 
systems. The focal point of this chapter will be the impacts of SOA and OA within the 
Defense Acquisition System decision support process and the acquisition lifecycle. 
Although this research will focus on the Defense Acquisition System and the acquisition 
lifecycle, the paper will also touch on a few impacts SOA and OA may have within the 
JCIDS process. Additionally, the Naval Open Architecture (NOA) policy guidance and 
its application to help develop SOA policy guidance will be discussed, as well as other 


factors affecting SOA and OA. 
B. DODD 5000.1 


The DoDD 5000./ is a directive that applies to all acquisition programs in the 
Department of Defense. The directive’s purpose is to provide management principles, 


mandatory policies, and procedures to managers for all current and future acquisition 
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programs. This directive provides definitions for the Defense Acquisition System, an 
Acquisition Program, the Defense Acquisition Executive (DAE), the Milestone Decision 
Authority (MDA), and the Program Manager (PM). The directive sets the policy and is 


the basic guidance required for all DoD acquisition programs. 
1. Policy 


The Defense Acquisition System is a complex and multi-faceted system utilized 
by the Department of Defense (DoD) in the acquisition of its National Security Systems. 
The purpose of the Defense Acquisition System is best described in the following quote. 

The Defense Acquisition System exists to manage the nation's investments 

in technologies, programs, and product support necessary to achieve the 

National Security Strategy and support the United States Armed Forces. 

The investment strategy of the Department of Defense shall be postured to 


support not only today's force, but also the next force, and future forces 
beyond that. (Under Secretary of Defense (AT&L), 2003a, p. 3) 


The Defense Acquisition System is governed by five fundamental policies: 
flexibility, responsiveness, innovation, discipline, and streamlined and effective 
management. Acquisition programs for SOA and OA are based upon principles that meet 
the requirements of these five governing policies. The following paragraphs will 
describe how SOA and OA support the five fundamental policies set forth in the DoDD 
5000.1. 


a. Flexibility 


SOA and OA systems, once established in an organization, provide 
flexibility through increased agility and potential re-use opportunities. As these systems 
mature, they increase flexibility, allowing the systems to adapt quickly to time-sensitive 


needs. 
b. Responsiveness 


SOA and OA provide the necessary responsiveness for deploying systems 


to the warfighter in the “shortest time practicable.” As stated previously, SOA should be 
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incorporated incrementally and will require considerable time to fully mature. 


Responsiveness will improve as SOA and OA systems mature. 


c. Innovation 


The DoD requires MDAs and PMs to explore innovative technologies to 
reduce cycle-times and costs. SOA and OA are proven innovative technologies in the 
commercial market and are gaining acceptance in the DoD. OA is intended to reduce 
costs and development times. The Navy has already realized the need to migrate to OA 
systems. SOA is intended to increase interoperability and reduce redundant systems and 
components, therefore reducing future cost and cycle-time associated with DoD 


networks. 


d. Discipline 


SOA and OA systems require the same level of discipline that is required 
of any acquisition program—the difference is in the baseline parameters. Since these 
technologies are relatively new, standard baseline parameters and exit criteria will need 


to be developed over time as data is gathered on programs using these technologies. 


e. Streamlined and Effective Management 


Streamlined and effective management can mitigate risks as each program 
is documented to produce credible cost, schedule, and performance parameters. 
Managers must be flexible, as these technologies will require multiple MDAs and PMs to 


mutually support programs across system and program boundaries. 


2 Modular Open Systems Approach (MOSA) 


The DoD recognizes the performance and total ownership cost advantages that a 
modular open-systems approach (MOSA) provides. “A modular, open-systems approach 
shall be employed, where feasible” (Under Secretary of Defense (AT&L), 2003a, p. 9). 
MOSA is defined as “an integrated business and technical strategy that employs a 


modular design and, where appropriate, defines key interfaces using widely supported, 
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consensus based standards that are published and maintained by a recognized industry 
standards organization” (OSJTF, 2004, p. 6). MOSA is considered a key enabler to 
evolutionary acquisition and supports many principles that are consistent with SOAs. 
Combining a MOSA with an SOA may reinforce the objectives presented in the OSJTF 
guide (2004). As seen in Figure 4, the principles and benefits that OSJTF states as being 
enabled by MOSA are also supported when using an SOA. 





Vision Principles Benefits 









Establish Enabling Environment Ease of Change 


MOSA is an 

integral part of all 

acquisition strategies to 
achieve affordable, 
evolutionary, 

and joint combat 

capability 


Employ Modular Design Reduced Total Ownership Cost 


Designate Key Interfaces Reduced Cycle-Time 


Enabling Joint Integrated 
Select Open Standards pps sd : 
Architectures and Interoperability 


Sela Mei leleuritas 


Risk Mitigation 








Indicators 


Figure 4. Modular Open Systems Approach from 
(OSJTF, 2004, p. 3) 


The guidance in the DoDD 5000.1 and the OSJTF guide mandate the use of open- 
systems architectures and support concepts integral to SOA. Instead of inhibiting SOA 
use, these documents enable SOA through the requirements established for using MOSA. 


OA and SOA are approaches that optimize total system performance and minimize total 


ownership costs. 
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The DoDD 5000.1 is the primary directive that must be followed by all 
acquisition programs. The DoDD 5000.2 is the instruction for the operation of the 


Defense Acquisition System and is discussed in the next section. 
C; DODI 5000.2 


The DoDI 5000.2 is the instruction for the operation of the Defense Acquisition 
System. This instruction establishes an acquisition management framework; creates a 
framework for developing technology opportunities; sets the requirement for using 
integrated architectures; and describes evolutionary acquisition as the preferred DoD 
strategy for rapid acquisition programs. This section will focus on the acquisition 
management framework, integrated architectures, evolutionary acquisition, and 


technology opportunities for the DoD acquisition programs. 
1. Defense Acquisition Management Framework 


The DoDI 5000.2 provides a “simplified and flexible management framework for 
translating mission needs and technology opportunities, based on approved mission needs 
and requirements, into stable, affordable, and well-managed acquisition programs that 
include weapon systems and automated information systems (AISs)” (Under Secretary of 
Defense (AT&L), 2003b, p. 1). The framework, provided by DoDI 5000.2, “authorizes 
Milestone Decision Authorities (MDAs) to tailor procedures to achieve cost, schedule, 
and performance goals” (p. 1). The flexibility of the acquisition management framework 
outlined in the DoDI 5000.2 and the ability to tailor it to the needs of the program is a key 
enabler for incorporating SOA and OA into IWS. The development processes of SOAs 
and OAs differ greatly from those of legacy systems and must be tailored to capture the 
objectives of the enterprise. Aligning an SOA or OA with the objectives of the enterprise 
necessitates flexibility within the acquisition management framework. Figure 5 
illustrates the defense acquisition management framework established by the DoDI 


5000.2. 
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Figure 5. Defense Acquisition Management Framework from 
(DAU, 2005, p. 49) 


Although the defense acquisition management framework was designed to help 
manage the acquisition of complex weapons systems rather than services (as defined in 
Chapter II), the basic management precepts can still be applied to SOA. The primary 
service delivery lifecycle stages when implementing an SOA are services-oriented 
analysis, service modeling, services-oriented design, service development, and service 
implementation (Erl, 2008b, p. 77). The acquisition of services can follow the basic 
outline of the defense acquisition management framework. The services-oriented 
analysis and modeling phases can be incorporated into the concept refinement phase; 
whereas, the services-oriented design phase fits into the technology development phase. 
Similarly, the service development phase fits within the system development and 
demonstration phase, and the service implementation phase fits within the production and 
deployment phase. Once the service or services enter the operations and support phase, 
service governance phases take over. The concept decision, milestone reviews, design 


readiness review, and full-rate production decision review can similarly be applied to an 
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SOA as it progresses through the service delivery lifecycle stages. The service delivery 
lifecycle stages of an SOA do not completely fit within the defense acquisitions 
management framework; however, the flexibility of the framework allows MDAs and 
Program Managers to tailor these procedures and processes to meet the needs of 


implementing an SOA. 


In February 2008, the Secretary of the Navy, Donald C. Winter, released a notice 
outlining improvements for the Navy’s requirements and acquisition process. The 
purpose of this document is 

To establish a review process to improve governance and insight into the 

development, establishment, and execution of acquisition programs in the 

Department of the Navy (DON). The goal of the review process is to 

ensure alignment between Service-generated capability requirements and 

acquisition, as well as improving senior leadership decision-making 


through better understanding of risks and costs throughout a program’s 
entire development cycle. (Winter, 2008, p. 2) 


The new process integrates a two-pass system with three gate reviews per pass 
into the acquisition lifecycle. The notice outlines the procedures for each pass and its 
associated review gates and establishes input and exit criteria for each gate, as well as the 
briefing content for each gate. The new process also establishes the System Design 
Specification (SDS) Development Plan, which is developed either during the Concept 
Refinement Phase or Technology Development Phase, depending on the milestone at 
which the program is initiated. The notice also establishes gate review membership, 
which includes a Chair, Principal Members and Advisory Members. The process flow is 
outlined for programs that are initiated at either Milestone A or Milestone B, as seen in 


Figures 6 and 7. 
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Figure 6. DON Requirements/Acquisition Two-Pass/Six-Gate Process with 


Development of a System Design Specification (illustrated example for program 
initiation at Milestone A) from 
(Winter, 2008, p. 9) 
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Figure 7. DON Requirements/Acquisition Two-Pass/Six-Gate Process with 


Development of a System Design Specification (illustrated example for program 
initiation at Milestone B) from 
(Winter, 2008, p. 10) 


As seen in Figures 6 and 7, this new process adds more decision reviews into a 
process that already has six. While the addition of these new decision review gates are 
meant to “establish a disciplined and integrated process” to be “implemented in an 
integrated, collaborative environment,” the amount of time and effort managing this 
decision review process becomes increasingly time-consuming and complex. The main 
purpose behind the defense acquisition management framework established in the DoDI 
5000.2 is to provide a simple and flexible management process. The addition of these 
new review passes and gates is contrary to the concepts of the defense acquisition 
management framework. The addition of the SDS Development Plan also adds time and 
complexity. The development of the SDS duplicates many of the requirements that are 


already covered in the Initial Capabilities Document (ICD) and the Capability 


37 


Development Document (CDD). Adding more review processes and documentation 
requirements will not be conducive to fielding systems that respond rapidly to changes in 


requirements and technology advances. 
2. Integrated Architectures 


The DoDI 5000.2 requires all “DoD components to develop joint integrated 
architectures for capability areas as agreed by the Joint Staff’ (Under Secretary of 
Defense (AT&L), 2003b, p. 3). IWS that use SOA and OA fall under the requirement for 
development as joint integrated architectures. These systems must be interoperable with 
the Global Information Grid (GIG) architecture and must be developed in accordance 
with the Joint Technical Architecture. The Navy must address impacts of using systems 
that take advantage of SOA and OA and determine the impact they have on the GIG and 
other joint systems. Interoperability is not only required within new systems the Navy 
develops, it is also imperative that new systems continue to enhance joint capabilities. 
During requirements and capabilities development, each military department and the 
related defense agencies are required to participate to ensure new systems enhance 


interoperability. 
3. Evolutionary Acquisition 


“Evolutionary acquisition is the preferred DoD strategy for rapid acquisition of 
mature technology for the user” (Under Secretary of Defense (AT&L), 2003b, p. 4). This 
acquisition method is intended for mature technologies that have proven benefits that can 
be quickly applied to improve military capabilities. Evolutionary acquisition relies upon 
updating requirements continuously to develop the most useful systems for users. Figure 
8 depicts the evolutionary acquisition strategy. This figure illustrates program initiation 
and the process through the evolutionary acquisition cycle. Feedback loops provide 


updated requirements and refine concepts as the program continues toward completion. 
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Figure 8. Requirements and the Acquisition Process from 
(Under Secretary of Defense (AT&L), 2003b, p. 4) 


There are two approaches to evolutionary acquisition, and a program may elect to 


use either. These approaches are spiral development and incremental development. 
a. Spiral Development 


Spiral development is the preferred development method for DoD 


acquisition programs. 


In this process, a desired capability is identified, but the end-state 
requirements are not known a program initiation. Those requirements are 
refined through demonstration and risk management; there is continuous 
user feedback; and each increment provides the user the best possible 
capability. The requirements for future increments depend on feedback 
from users and technology maturation. (Under Secretary of Defense 
(AT&L), 2003b, p. 4) 
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b. Incremental Development 


Although incremental development is not the preferred acquisition 
method, it is acceptable to use for programs that are not conducive to spiral development. 
“In this process, a desired capability is identified, an end-state is known, and that 
requirement is met over time by developing several increments, each dependent on 


available mature technology” (Under Secretary of Defense (AT&L), 2003b, p. 5). 
c. Combined Development 


SOA and OA are relatively new technologies within the DoD. To 
properly employ and mitigate risks with early SOA and OA development and 
implementation into Navy programs, both spiral and incremental development should be 
considered. Some requirements for IWS are well known and are unlikely to change in 
the near future; these programs would benefit from more traditional incremental 
development methods. As IWS systems mature to address emerging and future threats, 
many requirements are unknown and known requirements are likely to change to adapt to 


these threats; these systems will benefit better from spiral development. 


SOA is a prime candidate for systems requiring innovative technology in a 
highly dynamic environment. SOA provides the agility to rapidly adapt systems as 
requirements are updated and new requirements are realized. OA enhances SOA’s ability 


to adapt more rapidly due to OA’s alleviation of proprietary hardware and software. 
4. Technology Opportunities 


Rapid advances in technology and, more specifically, in software and network 
architectures provide opportunities for the Navy to enhance and expand IWS capabilities. 
SOA and OA are relatively new technological concepts that will allow Navy IWS to 
adapt rapidly as new requirements emerge. Interoperable systems requiring 


modifications will continue to expand as technology allows for improved networking. 
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The DoDI 5000.2 requires technologists and industry to seek new technology 
opportunities to facilitate future capabilities. SOA and OA are two opportunities to 
improve future capabilities. Developing an SOA does not require using open 
architectures and Navy IWS will benefit from using SOA alone. Using “an open, or at 
least elegant, architecture is key to forming a basis for independent modular variety: and 
through design specification and configuration management accountability is essential for 
managing the complexity of multiple product releases” (Dillard & Ford, 2007, p. 494). In 
case studies by Dillard and Ford, the advantages of using OA as the basis for 
architectures shows significant reduction in product cycle-time when using incremental 
or spiral development. OA complements SOA by improving modularity and reducing 
vendor specific product requirements. During spiral development, requirements are 
continuously updated to better meet user needs. Using OA to develop SOAs may provide 
the flexibility for more rapid changes to requirements during spiral or incremental 
development. Composable systems can reap the benefits of OA and SOA since these 


technologies provide the modularity for interoperability across multiple platforms. 


5; Summary 


The DoDD 5000.1 and DoDI 5000.2 include the guidelines for developing and 
acquiring emerging technologies such as SOA and OA. The DoD has realized the need 
for systems that meet needs of multiple platforms and that are capable of adapting to 
meet new threats. Reducing product cycle-times is imperative and Naval IT programs 
can no longer remain in a 3- to 5-year development cycle. Once established, OA and 
SOA will provide the foundation for more rapid modifications. These technologies will 
also lead to reduced costs, as composable systems become common in Navy IWS. The 
current acquisition system presently mandates OA to be considered when developing new 
systems. SOA provides the technology opportunities and capabilities that the directives 
and instructions require managers to consider. For example, much of the current effort in 
the surface domain is to transition the major combat systems to OA and to use the 
components to provide the basis for the new (CGX) combat system (Benedict, 2008, p. 
2). 
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D. JOINT CAPABILITIES INTEGRATION AND DEVELOPMENT SYSTEM 


As stated previously in the introduction to this chapter, SOA and OA have 
impacts within the Defense Acquisition System, JCIDS, and PPBE decision support 
systems. This section will highlight some of the impacts that SOA and OA may have on 
the JCIDS process. 


The JCIDS process “involves an analysis of Doctrine, Organization, Training, 
Material, Leadership and Education, Personnel and Facilities (DOTMLPF) in an 
integrated, collaborative process to define gaps in warfighting capabilities and propose 
solutions” (DAU, 2005, p. 39). As the DoD continually gravitates towards more joint 
warfighting capabilities, the “gaps” between legacy systems become more and more 
apparent. The lack of interoperability between legacy systems acquired through 
traditional “stove-piped” acquisition processes requires defense leadership to examine 
and analyze solutions that promote increased interoperability through the JCIDS process. 
The implementation of SOA and OA into future combat systems through the JCIDS 
process enables increased interoperability and promotes joint warfighting concepts. The 
JCIDS link to the Defense Acquisition System, as seen in Figure 9, provides the required 
analysis of the interoperability and integrated architectures of a defense acquisition 
program as it progresses through its acquisition lifecycle. The JCIDS process provides a 
top-down approach to determining essential warfighting capabilities. The top-down 
approach incorporates meaningful levels of analysis across the enterprise. To implement 
an SOA, a top-down approach is needed to emphasize the relationship between the 
business processes of the enterprise and the services that represent and implement the 


business logic (Erl, 2008b, p. 78). 
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Figure 9. JCIDS Link to Defense Acquisition from 
(DAU, 2005, p. 41) 


During the JCIDS process, the Initial Capabilities Document (ICD) is developed 
and “provides the definition of the capability need and where it fits in the broader 
concepts and architectures” (DAU, 2005, p. 40). Again, the ICD provides the top-down 
analysis approach needed to ensure that the services-orientation is applied to the required 
capabilities of the enterprise. The Capabilities Development Document (CDD) and the 
Capability Production Document (CPD) provide the Key Performance Parameters (KPP), 
which are the “attributes or performance characteristics considered most essential for an 
effective military capability” (p. 40). The utilization of SOA and OA should be reflected 
in the KPPs. 


E. CONTRACTING PROCESS 


Rendon’s Naval Postgraduate School research, Using A Modular Open Systems 
Approach in Defense Acquisitions: Implications for the Contracting Process, explored 
the use of the modular open systems approach (MOSA) as a method for implementing an 
evolutionary acquisition strategy and the implications it had on the contracting process 
(2006, p. 1). As stated earlier in this chapter, a MOSA supports many principles and 
benefits that are consistent with SOAs and OAs; therefore, Rendon’s assertions of the 
implications of a MOSA on the contracting process can be applied to SOA and OA. In 
his research, Rendon states: 

The program acquisition strategy should describe agency needs and 

objectives using mission-related or performance-based terms. In addition, 

the contracting strategy should flow from the acquisition strategy, and 

both should be consistent in goals and objectives. An acquisition strategy 

using a modular open systems approach should be focused on critical 

areas such as adopting evolving requirements, promoting technology 

transfer, facilitating system integration, leveraging commercial 

investment, reducing cycle-time and _ lifecycle cost, ensuring 
interoperability, enhancing commonality and reuse, enhancing access to 
cutting edge technologies and products from multiple suppliers, mitigating 
technology obsolescence risk, mitigating single source of supply risk, 


enhancing lifecycle supportability, and increasing competition. (Rendon, 
2006, p. 29) 


Similar to using a MOSA contracting strategy, the contracting strategy supporting 
an SOA- or OA-based acquisition strategy should be structured to achieve these MOSA 


objectives, which are consistent with many of the SOA and OA objectives. 


Rendon’s research further shows that “the solicitation for an acquisition program 
using an open systems approach will require specific language unique to the use of a 
modular open systems approach. Thus, the procurement documents that make up the 
solicitation should incorporate the specific language that reflects the preference or 
mandated use of a modular open systems approach in the acquisition program” (Rendon, 
2006, p. 36). Similar to a MOSA approach, solicitation for an acquisition using an SOA- 


or OA-based approach will require specific language that is unique to the use of SOA or 
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OA. Additionally, the procurement documents will require specific language that reflects 


the use of an SOA- or OA-based approach in the acquisition program. 


Rendon’s research also states that “in acquisition programs using a modular open 
systems approach, the government will want to incentivize the contractor to meet higher 
levels of “openness” in the design and development of the system” (2006, p. 57). For 
programs that intend to implement SOA and OA, program managers and contracting 
officers will need to develop an acquisition strategy and a contracting strategy that 
provides incentives to contractors to utilize SOA and OA principles and practices to 


achieve the high levels of “openness” desired for future [WS. 


Having realized the importance of the contracting process when acquiring and 
fielding systems that incorporate OA, the PEO-IWS developed an OA contracting 
guidebook for program managers. The Naval Open Architecture Contract Guidebook 
was developed to “provide Program Managers, Contracting Officers, and their supporting 
organizations with guidance and example contract language to assist them in 
incorporating Open Architecture principles into their contracts” (PEO-IWS 7, 2007, p. 1). 
Similarly, the Navy will need to develop a contracting guidebook for implementing SOA 
to provide program managers and contracting officers guidance for incorporating SOA 


principles into their contracts. 
F. NOA AND SOA POLICY GUIDANCE 


The purpose of this section is to review the current NOA policy guidance and to 
review how the Navy is developing its SOA guidance. As stated in the previous chapter, 
in the OA section, the NOA policy guidance is set forth in several DoD and Navy policy 
documents. In January 2006, CAPT James J. Shannon, Naval Open Architecture Program 
Manager, PEO-IWS 7.0, developed a brief delineating what program managers need to 
know about NOA. In that brief, he highlighted the major documents that help establish 
NOA policy guidance. The DoDD 5000.1 and the use of Modular Open Systems 
Approach (MOSA) were discussed earlier in this chapter. The following sections will 


cover the remaining policy guidance concerning NOA, adapted from Shannon’s brief. 
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if NOA Scope and Responsibilities 


The August 5, 2004, Assistant Secretary of the Navy (Research, Development & 
Acquisition) Policy Statement, entitled Naval Open Architecture Scope and 
Responsibilities, assigns responsibility and authority for directing the NOA effort to the 
Program Executive Officer (PEO) Integrated Warfare Systems (IWS) and establishes the 
OA Enterprise Team (OAET), which is to be chartered and led by PEO-IWS. It further 
states that the “OAET shall be responsible to defining an overarching OA acquisition 
strategy and develop guidance addressing incentives, intellectual property issues, 
contracting strategies and funding alternatives” (as cited in Shannon, 2006, January, p. 6). 
It also states that the OAET “shall prepare, staff, and promulgate a Navy-wide OA 
business strategy” (p. 6). Additional OAET roles and responsibilities outlined in the 
ASN(RD&A)’s memo are below: 

e Lead the Navy Enterprise to OA implementation 


e Provide OA Systems Engineering leadership to PEO’s, industry 
partners, Joint Organizations, Navy Warfare Centers and other 
participating organizations 


e Provide the forum and process by which cross domain OA 
proposals and solutions are utilized across domains 


° Identify cross-domain components and opportunities for cost 
reduction and reuse 


° Leverage technical, business, and organizational solutions from all 
participating communities 


e Establish an advisory team, comprised of industry and academia, 
to interpret and advise the team on an as periodic basis (p. 7) 


2. Memorandum of Understanding 


The December 3, 2004, Memorandum of Understanding (MOU) among PEO- 

IWS, PEO SUBS, PEO (T), PEO C4I, and PEO Space Systems made the OAET 

responsible for the OA effort across the Naval Enterprise, including ensuring 

implementation conforms to MOSA policy and requirements, ensuring that OA progress 

assessments comply with the Program Assessment Review Tool (PART), and promoting 

NOA Enterprise products to OSD, DoD agencies and other Service components (as cited 
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in Shannon, 2006, January, p. 8). The MOU is under revision at present, and will expand 
the participation to include additional PEOs, OPNAV codes and SYSCOM technical 
authorities (Wessman, 2008). 


3. OA EXCOMM Action Items 


The 15 May 2005 ASN(RD&A) Memorandum summarizing OA EXCOMM III 
of February 22, 2005, required ACAT I programs to use the OA Assessment Model 
(OAAM) to determine the “as-is” level of openness and desired “to-be” state and to 
produce metrics and conduct business case analyses if necessary (as cited in Shannon, 
2006, January, p. 11). As stated in the previous chapter in the OA section, the OA 
assessment model and an assessment tool were developed to help program managers 


evaluate the “openness” of their respective program or system. 


4. OPNAV Requirements 


The December 23, 2005, Deputy Chief of Naval Operations (Warfare 
Requirements and Program) (N6/N7) Requirement for Open Architecture (OA) 
Implementation “established the requirement to implement Open Architecture (OA) 
principles across the Navy Enterprise” (as cited in Shannon, 2006, January, p. 15). It also 
established the OA Council (OAC) of representatives of N6/N7 Division Directors to 
work with the OAET on the requirements set forth in the ASN(RD&A)’s August 5, 2004 
Memorandum. The letter also directs the OAC, PEO-IWS 7.0, and the OAET to focus 
assessment priorities in support of the following capabilities: track management, combat 
identification (CID), data fusion, time-critical targeting and strike, and integrated fire 


control (p. 15). 


5. NOA Policy and Guidance Summary 


Over the last several years, the Navy has spent considerable time and effort 
developing its NOA policies and guidance to best implement open architecture into 
acquisition strategies. The policies discussed previously have set the foundation the 


Navy needs to successfully implement OA. The Navy has also developed guidance 
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documents to help program managers implement OA into their respective programs, 
which includes the NOA Contract Guidebook. The Navy has also developed the NOA 
website that contains all the information concerning NOA. In short, the Navy’s policies 
and guidance concerning OA have begun to catch up with the commercial market and 
should facilitate the implementation of OA into future combat systems acquisition 


processes. 
6. SOA Policy and Guidance 


In April 2006, the Navy’s Chief Information Office (CIO) chartered the 
Department of Navy (DON) SOA Transformation Group (Wennergren, 2006). The DON 
SOA Transformation Group 

will provide the direction for Commands to align to a DON Net-Centric, 

interoperable environment, based on a Service-Oriented Architecture 

ensuring all services are visible, trusted, accessible and usable—when 
needed and where needed-to accelerate the decision cycle process 


throughout the DON WarFighter community, via web-centric technology. 
(Wennergren, 2006, p. 1) 


Similar to the OAET, the DON SOA Transformation Group is responsible for 
developing a DON SOA policy, a DON SOA Concept of Operations (CONOPS), 
metrics, and Return on Investment (ROI) models. They will also be responsible for 
developing white papers that will include best practices for implementing SOA, 
acquisition strategy recommendations for implementing SOA and certification and 


accreditation policies (p. 2). 


Although the DON SOA Transformation Group has yet to deliver any official 
policies or guidance concerning the implementation strategy the Navy will utilize with 
regards to SOA, the ball is at least rolling in the right direction. The Navy’s promotion of 
SOA, along with its policies and guidance for implementing OA, are beginning to 
prepare the Navy for new business and technology trends that will impact the acquisition 


of future combat systems. 


48 


G. OTHER FACTORS 


i Horizontal Systems Engineering 


In December 2004, The Assistant Secretary of the Navy, John J. Young, Jr., 
released a memorandum stating the need for cross-platform commonality with 
engineering systems. The current vertical management of acquisition programs 
complicates cross-platform commonality, since decisions are delegated to prime 
contractors. The prime contractors limit system modularity by optimizing “their 
particular business models rather than ours” (Young, 2004, December 23, p. 1). Young 
recognizes the need for Executive Committees (EXCOMM) to promote cross-platform 
commonality by developing “action paths” that lead to horizontal systems integration 
across multiple platforms. “The product of these EXCOMMs will be recommendations 
and action assignments for my signature to develop architectures, roadmaps and 
implementation plans to increase commonality” (p. 1). The result of the 


recommendations will lead to enterprise-wide commonality in hardware and software. 


SOA combined with OA provides the mechanisms for initiating horizontal 
integration for [WS through hardware and software based on OAs and SOAs. OA 
mitigates risks associated with prime contractors utilizing proprietary software and 
hardware to optimize their business models and creates flexibility for the Navy when 
integrating systems across multiple platforms. SOA allows for increased modularity and 
interoperability in IWS that require common capabilities but have varying mission 
requirements. SOA combined with OA supports horizontal systems engineering and 
provides a path for the transition from a vertical acquisition to horizontal acquisition 


process. 


2. PEO-IWS 


The PEO-IWS vision states: “PEO IWS leads a professional and experienced 
organization that delivers Enterprise solutions for Naval warfare systems that operate 
seamlessly and effectively within the Fleet and Joint Force” (Department of the Navy, 


2008). The PEO-IWS is intended to facilitate the transformation of the acquisition 
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process from the current vertical process to a more horizontal process. Jesse M. Mink’s 
Naval Postgraduate School thesis, Analysis of Horizontal Integration within the Program 
Executive Office, Integrated Warfare Systems, suggests barriers exist that prevents PEO- 
IWS from facilitating its mission. The following excerpt from Mink’s thesis states the 
PEO-IWS function. 

PEO IWS was founded to oversee design, construction, and maintenance 

of all surface ship and submarine combat systems. The stated intent of this 

re-organization was to shift from a platform-centered approach to a more 

integrated consistent approach across all combat systems. PEO IWS is the 

entity charged with coordinating the integration of warfare systems into a 

single, functioning system of systems that can then be integrated onto any 

platform. Integration of the warfare system and the ship itself requires 


harmonization and communication between and across PEO IWS and its 
stakeholders. (Mink, 2006, p. 22) 


Although the PEO-IWS plays an integral part when deciding what new IWS 
should be developed for the Navy’s ships, the funding is distributed to other PEOs such 
as PEO Carriers or PEO Ships. This funding structure does not provide the flexibility 
necessary for PEO-IWS to horizontally integrate common systems into various platforms. 
Distributing the funding for IWS directly to PEO-IWS would alleviate the problems with 
disparately acquired systems that reduce interoperability. Providing interoperable 
systems by managing common systems acquisition programs from a single PEO can lead 
to more rapid acquisition, increased interoperability, and cost reductions. The PEO-[WS 
must not only be involved in the acquisition process for [WS but must also be responsible 
for maintenance actions that require system changes. Managing IWS for all ships will 
reduce interoperability issues arising from changes to one platform and the effects the 
changes will have on other platforms. As SOA- and OA-based IWS are horizontally 
integrated on naval platforms, system modifications overseen by PEO-IWS will provide 
rapid systems changes and ensure the systems remain interoperable to enhance warfighter 


capabilities. 
3. Information Technology Portfolio Management 


In October 2005, the Acting Deputy Secretary of Defense, Gordon England, 
issued a DoD Directive that “establishes policy and assigns responsibility for the 
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management of DoD information technology (IT) investments as portfolios that focus on 
improving DoD capabilities and mission outcomes” (Assistant Secretary of Defense 
(NH/DoD CIO), 2005, p. 1). The policy further states that “IT investments shall be 
managed as portfolios to: ensure IT investments support the Department’s vision, 
mission, and goals; ensure efficient and effective delivery of capabilities to the 
warfighter; and maximize return on investment to the Enterprise” (Assistant Secretary of 


Defense (NII/DoD CIO), 2005, p. 2). 


In the article “Best practices for Building SOA Applications,” seven steps to SOA 
adoption are identified. One of the key steps to effective SOA adoption is to create a 
portfolio of services (SYS-CON Media Inc., 2008, p. 2). As stated before, an SOA 
models the business or enterprise as a collection of self-contained services, which are 
implementations of a well-defined piece of business functionality. In the DoD, a well- 
defined piece of business functionality can be viewed as a capability. DoD Instruction 
8115.02 states “managing portfolios of capabilities aligns IT with the overall needs of the 
warfighter, as well as the intelligence and business activities which support the 
warfighter” (Assistant Secretary of Defense (NII/DoD CIO), 2006, p. 3). By 
implementing an SOA, the DoD can better manage its IT investments as a portfolio of 
services that implement well-defined pieces of business functionality (capabilities) that 
support the Enterprise’s vision, mission and goals while ensuring efficient and effective 


delivery of capabilities to the warfighter. 
DoDI 8115.02 also states that IT portfolio management 


is a key enabler of information sharing. In accordance with DoD 
Directive 8320.2 (Reference (m)), portfolio management enables data 
sharing across Components, supports cross-Component communities of 
interest, and ensures data sharing agreements are implemented by the 
respective Components. These activities should maximize return on 
investment for the enterprise by reusing accessible data rather than 
recreating existing data. (Assistant Secretary of Defense (NII/DoD CIO), 
2006, p. 5) 


One of the key tenets of an SOA is re-use. By managing an SOA as a portfolio of 


services, different components within the Enterprise can leverage services developed by 
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other components, alleviating redundant capabilities while maximizing return on 
investment for the entire Enterprise. Utilization of an SOA within the Navy and the rest 


of the DoD will help facilitate the management of IT investments as portfolios. 
H. SUMMARY 


This chapter discussed the current Defense Acquisition System, analyzed how 
SOA and OA can be integrated into the current processes and addressed the current NOA 
policies and the Navy’s future roadmap for SOA policies. It also discussed other factors 
affecting the implementation of SOA and OA, with regards to Horizontal Systems 
Engineering, the current PEO-IWS structure and IT portfolio management. The main 
focus of this chapter was to answer the first thesis question: “Does the Defense 
Acquisition System need to be altered to take advantage of SOA and OA implementation 


into the acquisition lifecycle?” 
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IV. CASE STUDY 


A. INTRODUCTION 


The previous chapter discussed the impacts of SOA and OA within the Defense 
Acquisition System. The focus of this chapter is to analyze the Navy’s SOA 
implementation within the Consolidated Afloat Networks and Enterprise Services 
(CANES). The first section gives a broad overview of CANES and what it is trying to 
accomplish. The next section will discusses how the Navy plans to implement SOA 
within CANES and how it adheres to SOA and OA principles and practices. The 
following section will discuss how CANES will utilize SOA and OA to provide future 
IWS capabilities. This chapter and this case study will provide answers to the second and 
third thesis questions, “Do current Navy OA policies and SOA practices provide the 
necessary interoperability requirements for future IWS?” and “What benefits might SOA 
and OA provide to [WS?” 


B. CANES OVERVIEW 


Currently, there are a multitude of legacy standalone afloat networks throughout 
the Navy. These legacy standalone systems were developed and fielded by multiple 
acquisition programs and program offices throughout the Navy. These legacy network 
systems represent the “stove-piped” acquisition strategies of the past. In order to move 
forward and eliminate these “stove-pipes,’ the Navy implemented CANES as an 
integrated approach to consolidate and reduce the number of afloat networks. Figure 10 


depicts how CANES intends to consolidate the legacy afloat networks. 
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Figure 10. CANES Roadmap from (SPAWAR, 2007a, p. 2) 


The Navy’s vision for CANES was developed based on “an overarching concept 
to reduce the number of afloat networks, providing efficiency through a single 
engineering focus on technical solutions” (SPAWAR, 2007a, p. 1). This reduction of 
networks “allows for streamlining acquisition, contracting, and test events, and 
efficiencies in the reduction of multiple Configuration Management (CM) baselines, 
logistics and training “tails” into a unified support structure” (p. 1). In order to achieve 
this, the CANES vision established four equally important goals 


Goal 1-Collapse the number of networks in the current N6 afloat network 
portfolio by use of cross-domain technologies. 


Goal 2-Reduce the infrastructure footprint and associated costs for 
hardware afloat. 
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Goal 3-Provide capability to meet current and projected warfighter 
requirements. 


Goal 4—Extend network consolidation goals to naval programs outside the 
current N6 afloat network portfolio. (p. 1) 


These goals demonstrate the Navy’s desire to eliminate the “stove-piped” 
acquisition processes of the past. Consolidating these legacy networks allows the Navy 
to reduce infrastructure and provide increased capabilities while lowering lifecycle costs. 
In order to integrate the legacy network systems, the CANES program will implement an 


infrastructure that supports a Services-oriented Architecture (SOA). 
C. ADHERENCE TO SOA AND OA PRINCIPLES AND PRACTICES 


CANES development is predicated upon adhering to common SOA and OA 
principles and practices. SOA and OA principles and practices were described 
previously in Chapter II. The focus of the second thesis question is current Navy OA 
policies and SOA practices. This section will analyze the principles and practices 
CANES is following and determine if this program is adhering to common SOA and OA 


practices. 


A significant CANES goal is to utilize SOA and OA to breakdown the current 
“stove-pipes” and replace the current network structure with a more interoperable and 
adaptable solution. Figure 11 illustrates a high-level depiction of the current network that 


must be transformed to incorporate an SOA. 
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Figure 11. 


Exchange of Information Across Multiple Secure Naval Networks 


from (SPAWAR, 2007b, p. 4). 


I, CANES RFI 


The Space and Naval Warfare Systems Command (SPAWAR), the Program 


Executive Office-Command, Control, Communications, Computers, Intelligence (PEO- 


C41), Networks, Information Assurance (IA), and Enterprise Services Programs Office 


(PMW 160) distributed a Request for Information (RFI) to obtain information for 


possible development of the CANES system. Within the RFI, the aforementioned 


organizations list five CANES key objectives 


Increased network reliability and efficiency 
Interoperable, distributable, and loosely coupled 
A tiered model of service interactions 

Improved control over costs 


A scalable tiered model of service interactions (SPAWAR, 2007b, 
p. 4) 


Interoperability is an increasing concern with naval networks. The Navy’s future 


IWS systems must be interoperable and reliable. Interoperability is the biggest benefit 


SOA provides. SOA aims to reduce interoperability issues and therefore increase system 


reliability among naval platforms. The CANES system is based on SOA and OA 
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principles that promote interoperability. The CANES system development process has 
realized SOA, based on open standards, can provide the solution to increase 


interoperability among naval platforms. 


The loose coupling within the CANES system is one of the key tenets of an SOA. 
Loose coupling is an SOA design goal to reduce the dependency between services, while 
still providing interoperability within a system. Although loose coupling is desired in an 
SOA, interoperability has greater importance. Services should only have reduced 
dependency to a degree that still allows interoperability between multiple services and 


across multiple applications. 


Transitioning to a more horizontal acquisition structure will provide improved 
control over costs. An incremental approach should be adopted when implementing an 
SOA. CANES is planned as an incremental implementation beginning with core services 
and incorporating new services as needed. As common systems are implemented across 


varying platforms, costs should be reduced. 


The Navy requires that CANES is scalable. SOA is intended to provide 
scalability by reducing duplicative service implementations. Current systems will be 
replaced with systems that utilize interoperable core services. A tiered model of service 
interactions will standardize the CANES system by using common interfaces. “By 
adhering to standardized interfaces, systems can utilize common services which will 


reduce the cost and consolidate the maintenance of the systems” (SPAWAR, 2007b, p.5). 


“Two main tenets of CANES enterprise service architecture are: 1) an adherence 
to standards, and (2) technology/vendor neutrality” (SPAWAR, 2007b, p. 7). Navy OA 
policies and practices promote the development of interoperable and reusable 
applications through common standards and interfaces, which leads to open competition 


and technology neutrality. 


The CANES RFI is a positive step towards developing an SOA utilizing OA 


practices and principles. 
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2: CANES SOA Reference Architecture 


To properly implement an SOA, CANES is using the OASIS SOA reference 
model. The OASIS model “is an abstract framework for understanding significant 
entities and relationships between them within a service-oriented environment, and for 
the development of consistent standards or specifications supporting that environment” 
(MacKenzie et al., 2006, p. 1). This model provides the necessary framework to develop 
an SOA and provides an abstract reference model that can be applied to SOA regardless 
of technology implementation. The OASIS reference model for SOA’s relationship to 


other system work is depicted in Figure 12. 
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Figure 12. How the Reference Model Relates to Other Work from 
(MacKenzie et al., 2006, p. 5) 


Utilizing the OASIS reference model provides CANES the flexibility to adapt to 
emerging needs for various platforms. Using the OASIS reference model is an example 


of how the Navy is following industry standards for accepted SOA practices. 


The Reference Model (RM) of current interest is an abstract framework 
for understanding significant entities and relationships between them 
within a service-oriented environment, and for the development of 
consistent standards or specifications supporting that environment. It is 
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based on unifying concepts of SOA and may be used by architects 
developing specific service-oriented architectures or in training and 
explaining the SOA paradigm. A reference model is not directly tied to 
any standards, technologies or other concrete implementation details (such 
as "Web Services"). Hence, a good reference model provides common 
semantics that can be used unambiguously across and between different 
implementations. (Nickull, 2006) 


The CANES SOA reference architecture identifies several qualities that must be 
addressed in the implementation of the CANES services infrastructure. The qualities 


addressed by the CANES SOA reference architecture are 


e Interoperability 

e Quality of Service 

e Loose Coupling 

* Service Operations Management 
® Service Lifecycle Management 
e Service Metadata Management 


e SOA Governance (MITRE Corporation, 2007, p. 3-1) 


Chapter II of this thesis outlined several of the basic SOA concepts and principles. 
The qualities outlined in the CANES SOA reference architecture mirror those concepts 


and principles. 


An SOA based on common services provides seamless interaction with new and 
legacy systems regardless of platform specific characteristics. “The CANES Services 
Infrastructure must integrate disparate application environments” (MITRE Corporation, 
2007, p. 3-1). By using common services and interfaces, legacy systems can become 
encapsulated enabling communication between disparate environments, which increases 


interoperability. 


The CANES Services Infrastructure “must ensure the delivery of acceptable 
levels of service in terms of security, performance, and integrity” (MITRE Corporation, 
2007, p. 3-1). An SOA must provide different priority levels to data flows that provide 


the security and integrity of the data while maintaining the necessary flow of critical data. 
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An SOA design goal is to reduce the dependency between services while still 
providing interoperability within a system through loosely coupled services. The 
CANES SOA reference architecture identifies the importance of loose coupling as “a 
core SOA design principle that ensures flexibility, reusability, and resiliency in the face 


of dynamic systems” (MITRE Corporation, 2007, p. 3-2). 


The CANES SOA reference architecture identifies the necessity to provide 
Service Operations Management, Service Lifecycle Management, and Service Metadata 
Management. When implementing an SOA, services are defined and designed as a piece 
of business functionality. Similar to a business, an SOA must provide the operations and 
lifecycle management of the business or service functionality. Since the metadata of a 
service describes the different aspects of the service and its capabilities, it to must be 


managed as a business functionality. 


Governance refers to the application of processes utilized throughout an 
organization when developing an SOA. These processes govern how SOAs are designed, 
developed, implemented and maintained, which ensures conformity to the guiding 
architectural principles and regulations established by the organization. The CANES 
SOA reference architecture states that governance policies “should be defined that dictate 
or provide guidance for service creation, service testing, service utilization, service 
management, and service versioning’ (MITRE Corporation, 2007, p. 3-6). These 
governance policies will help ensure that CANES utilizes SOA principles, processes and 


best practices throughout its development. 


D. CANES SOA AND OA USE TO PROVIDE FUTURE IWS CAPABILITY 


The benefits that SOA and OA provide to IWS are the focus of the third thesis 
question. This section will identify some of the benefits of CANES and how its 


development can help provide future [WS capabilities. 


1. Joint Interoperability 


While CANES is a Navy system that is being developed for ships, it must not 


only be interoperable with other shipboard network system, it must also be interoperable 
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with joint systems. The Army, Air Force, and the Marine Corps are developing SOA- 
based systems. The Navy is collaborating with the other services, using a Multi-service 
SOA consortium (Figure 13), to ensure standard interfaces and specifications are utilized 


to meet joint interoperability requirements. 


Multi-Service SOA Consortium 
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Figure 13. Multi-Service SOA Consortium from 
(PEO-C4I, 2008, p. 26) 
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As each military service develops SOA- and OA-based systems, it is critical that 
common standards are used. Figure 14 depicts the interaction of each military service’s 
SOA interactions. “A DoD/DNI Enterprise Services Technical Governance Forum is 
validating a set of common standards, specifications, and reference implementations to 
enable joint interoperability across a multi-Service/Agency SOA” (PEO-C4I, 2008, p. 
28). As each military service’s particular SOA program matures, governance is 
increasingly important. A governance organization should be independent from any 
particular military component to autonomously monitor changes within each military 
service’s SOA in order to mitigate risks associated with interoperability. This 
organization should continue to provide guidance throughout the lifecycle of all military 


SOA systems. 
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Figure 14. Multiple SOA Initiatives Being Developed for Each Military Service 
from (PEO-C4I, 2008, p. 22) 


CANES is taking positive steps toward successful joint interoperability by 
participating in the Multi-Service SOA Consortium collaboration effort to develop 
common standards that will provide the necessary measures for joint interoperability. 
Increasing the success of joint interoperability is the goal of the Enterprise Services 


Technical Governance Forum. Figure 15 is a diagram of the forum’s basic structure. 
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Figure 15. DoD/DNI Enterprise Services Technical Governance Forum 


from (PEO-C4I, 2008, p. 27). 


The DoD CIO and the Director of National Intelligence (DNI) CIO are co- 
chairing the forum and providing guidance as new recommendations for enterprise 
services implementation. This is a promising endeavor that may improve joint 
interoperability. This forum is set up for implementation, but a similar organization must 
exist to continue to govern each new service as systems evolve. A permanent governance 
board will ensure joint interoperability continues as new services are added and obsolete 


services are removed. 
2, Cost Savings 


The CANES system is currently in an early acquisition phase. Multiple industry 
days and RFI’s have been issued, but the RFP will not be available until August 2008. 
The Navy is still seeking input from industry before finalizing CANES initial 
requirements; therefore, funding requirements are not clear at this time. Although 
funding for CANES is still undetermined, $21.6 million has been allocated to CANES for 
FY2009 (Roughead, 2008, p. 6). This system is considered “mission critical for the fleet 
and is a priority for Navy leadership” (SPAWAR, 2008, p. 3). CANES is expected to 


reduce total ownership costs through the use of SOA and OA. The commercial market 
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has already shown the cost benefits of using SOA (Erickson, 2006, p. 6). As DoD SOA 
and OA initiatives materialize, cost savings should be realized through greater 


commonality and reduced redundancy. 


In 2001, AT&T adopted the use of Web-services that would move towards a true 
SOA by 2003. The initial resistance to using an SOA was solved by AT&T’s senior vice 
president stating "Thou shalt use Web services," and "If you don't use Web services, 
you'll get fired” (McKendrick, 2006). This example of change management was required 
to move AT&T towards using a true SOA. The benefits have shown real cost savings 
within 5 years of starting its SOA initiative. “By 2005 AT&T had documented over $40 
million in savings from SOA” (Erickson, 2006, p. 6). AT&T also projects that it will see 
an additional $100 million in cost savings by 2009. AT&T has benefited from SOA’s 
ability to re-use services, reduce maintenance through reduced interfaces and versioning, 
and increase commonality across SOA customer interfaces. Figure 16 illustrates the cost 


savings AT&T was able to achieve by the re-use of a single service across 5 clients. 


2.6M 


2.1M 


1.6M 


1.1M 


$ Cumulative Savings 


Initial 
Service 





2003 Year 2005 
Figure 16. AT&T Cost Savings from (Erickson, 2006, p. 6) 
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AT&T is a large enterprise that can be compared to the Naval enterprise. The 
Navy Leadership has already mandated using OA and considers SOA a priority. 

The Consolidated Afloat Networks and Enterprise Services (CANES) 

system achieves an open, agile, flexible and affordable network 

architecture that will move us forward. CANES embraces cross-domain 

solutions that enable enhanced movement of data. It is a revolutionary 


change in our information technology infrastructure and it is absolutely 
vital for us to excel in 21st century warfare. (Roughead, 2008, p. 6) 


Roughead’s statement is similar to the AT&T vice president’s statement in that it 
embraces the use of SOA (through CANES). Just as AT&T has benefited through its 
SOA implementation, the Navy can expect to achieve similar benefits through its SOA 
implementation with CANES. As the number of clients/customers of the services 
provided by AT&T’s SOA increases, their cost savings increase. As the Navy 
implements CANES across different platforms, it too can expect an increase in cost 
savings. Greater cost savings will accrue as DoD military components increase 


information sharing among each military service through common SOA interfaces. 
E. SUMMARY 


This chapter analyzed the Navy’s SOA implementation within CANES. The 
chapter started with a broad overview of CANES and what it is trying to accomplish, then 
it discussed how the Navy plans to implement SOA within CANES and how it adheres to 
SOA and OA principles and practices. The chapter then discussed how CANES will 
utilize SOA and OA to provide future IWS capabilities. This chapter and this case study 
provided answers to the second and third thesis questions, “Do current Navy OA policies 
and SOA practices provide the necessary interoperability requirements for future [WS?” 


and “What benefits might SOA and OA provide to [WS?” 
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V. CONCLUSIONS AND RECOMMENDATIONS 


A. CONCLUSIONS 


The main purpose of this thesis was to analyze whether the Defense Acquisition 
System needs to be altered to take advantage of the implementation of Services-oriented 
Architecture (SOA) and Open Architecture (OA) principles into the acquisition of 
Integrated Warfare Systems (IWS). The research behind this thesis had several 
objectives. The researchers began by examining SOA and OA principles and processes 
to satisfy the first objective of determining the relational architecture between SOA and 
OA systems. The researchers then examined the Defense Acquisition System and the 
acquisition lifecycle to satisfy the second objective of determining the feasibility of 
moving toward SOA and OA systems. This examination of the Defense Acquisition 
System then lead to satisfying the third objective of identifying any possible constraints 
within the Defense Acquisition System that would prevent the implementation of SOA 
and OA in IWS. The researchers examined the Consolidated Afloat Networks and 
Enterprise Services (CANES) program to satisfy the fourth objective, which was to 
determine the best practices of a Naval acquisition program that is currently 
implementing SOA and OA into its acquisition process. Finally, the researchers 
examined some other Navy and DoD initiatives to satisfy the final objective of 
establishing some successful realignments of the Defense Acquisition System to allow 


new technology acquisition in military organizations. 


The research objectives of this thesis were established and fulfilled to enable the 
researchers to answer three thesis questions; “Does the Defense Acquisition System need 
to be altered to take advantage of SOA and OA implementation into the acquisition 
lifecycle?”, “Do current Navy OA policies and SOA practices provide the necessary 
interoperability requirements for future [WS?” and “What benefits might SOA and OA 
provide to [WS?” 
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Chapter III provided a detailed examination of the Defense Acquisition System 
and the answer to the first thesis question, “Does the Defense Acquisition System need to 
be altered to take advantage of SOA and OA implementation into the acquisition 
lifecycle?” From the analysis of the current Defense Acquisition System, the researchers 
conclude that the implementation of SOA and OA does not require a necessity to alter the 
current processes. The requirement for using a modular open systems approach (MOSA) 
within the Defense Acquisition System enables rather than inhibits implementing SOA 
and OA. Although the service delivery lifecycle stages of an SOA do not completely fit 
with the defense acquisition management framework, the flexibility of the framework 
allows the procedures and processes to be tailored to meet the needs of implementing an 
SOA. The DoDD 5000.1 and DoDI 5000.2 provide the necessary guidelines for 
developing and acquiring emerging technologies such as SOA and OA. The emphasis of 
implementing SOA and OA into future IWS needs to come from the policies and 
guidance set forth by the Navy. To further OA use within Naval systems, the Navy 
should begin to combine the use of OA with other emerging technologies such as SOA 
and service-oriented computing. The Navy must eliminate the traditional “stove-piped” 
acquisition process (in which each platform acquired its own combat systems) and move 
toward a horizontal acquisition process in which combat systems are acquired and 


integrated across multiple platforms. 


Chapter IV provided a short analysis of the CANES program and the answers to 
the second and third thesis questions, “Do current Navy OA policies and SOA practices 
provide the necessary interoperability requirements for future IWS?” and “What benefits 
might SOA and OA provide to IWS?” After analysis of the CANES program, the authors 
concluded that the Navy is proceeding in the correct direction to meet future warfighter 
needs by using OA and SOA in CANES to support future WS. Although CANES is still 
in its infancy as a program, having not yet released an RFP, it is following current SOA 
and OA policies and practices in order to provide the interoperability requirements the 
Navy desires for future IWS. As the Navy continues to develop CANES, following 
commonly accepted SOA methods and best practices will increase the program’s success. 


Since requirements are likely to evolve as CANES development and implementation 
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progresses, adherence to common SOA and OA principles and practices will provide the 
necessary interoperability and agility for future IWS. CANES participation in the Multi- 
Service SOA Consortium is a positive step toward increasing joint interoperability. The 
potential cost savings benefit from CANES and the increase in information sharing is 
also evident. As illustrated in Chapter IV, AT&T has demonstrated the benefits of 
migrating from legacy systems to SOA. Cost savings and improved information sharing 
will increase the Navy’s and the other military services’ warfighting capabilities in the 
future. The CANES program is the first step towards moving from the Navy’s current 
IWS systems to future systems that capitalize on the benefits of utilizing OA and SOA. 
CANES is an early step toward shifting the Navy’s acquisition system from a vertical 
“stove-piped” process to a more horizontal process that will provide the necessary 


interoperability requirements for future IWS. 


B. RECOMMENDATIONS 


Based on their conclusions, the researchers have developed several 
recommendations that will facilitate the Navy’s transition from a vertical “stove-piped” 
acquisition process to a horizontal acquisition process. The first recommendation is to re- 
structure the current PEO system. Chapter HI discussed the concepts behind the creation 
of PEO-IWS and the limitations it faces due to current funding structures. In order to 
create a truly horizontal acquisition process and integrating combat systems across 
multiple platforms, the Navy should consider re-structuring the current PEO 
system—providing PEO-IWS with not only the authority and responsibility to design, 
construct and maintain integrated combat systems, but also to provide them with the 


proper funding and the control of that funding. 


The second recommendation is to establish SOA policies and guidance within the 
Navy and the DoD. The Navy’s policies and guidance concerning OA have begun to 
catch up with the commercial market and should facilitate the implementation of OA into 
future combat systems acquisition processes. The DON SOA Transformation Group 
should capitalize on the current Naval OA policies and guidance when developing its 


SOA policies and guidance. The Navy will also need to develop a contracting guidebook 
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for program managers and contracting officers’ guidance for implementing SOA into 
their contracts. Similar to the Navy’s OA contract guidebook, the SOA contract 
guidebook should contain suggested language for Sections C, H, L, and M as well as 
recommendations that provide incentives to contractors for utilizing SOA. SOA 
principles and policies combined with OA principles and policies supports horizontal 
systems engineering and provides a path for the transition from a vertical to a horizontal 


acquisition process. 


The third recommendation is for the DoD to establish a continuous joint SOA 
governance board led by DoD personnel not affiliated with a particular military service. 
Joint interoperability is imperative for all future DoD IT systems. SOA standards are 
currently in development through the Multi-Service SOA Consortium and the Enterprise 
Services Technical Governance Forum. These organizations are intended to develop 
common standards to increase the interoperability throughout all military services. Using 
these organizations increases the likelihood of each military service’s SOA program to be 
interoperable when implemented, but it does not provide the necessary means for 
maintaining interoperability as systems mature. The establishment of a continuous joint 
SOA governance board will provide the necessary governance to maintain joint 
interoperability as systems change. The board will monitor changes to any military SOA 


program, ensuring new service implementations adhere to approved standards. 
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VI. FUTURE WORK 


While conducting the research and writing for this thesis, the researchers 
identified several issues that could be developed and addressed by future NPS thesis 


students. 
1. Evaluation of the PEO System 


One of the recommendations of the researchers is the re-structuring of the PEO 
system. One of the limitations facing PEO-IWS is the current funding structure. A thesis 
could be developed that would evaluate the current PEO system in order to identify 
constraints within the PEO structure that inhibits the transition from a vertical to a 
horizontal acquisition process. The thesis could then develop recommendations on how 


to re-structure the PEO system to enable a horizontal acquisition process. 
Zz; SOA Policy and Guidance Development 


Another recommendation provided in this thesis is the development of the Navy’s 
SOA policies and guidance. A thesis student could work directly with the DON SOA 
Transformation Group to develop a thesis that would provide an evaluation on both the 
Navy’s current OA policies and guidance along with the best practices of the commercial 
SOA implementations. This thesis could provide recommendations for the development 


of the Navy’s SOA policies and guidance. 
a SOA Contracting Implications 


This thesis briefly discussed the similarities between a modular open systems 
approach (MOSA) acquisition strategy and its implication on the contracting process and 
the implications of SOA within the contracting process. A graduate student could 
research and develop a thesis that evaluates the implications of SOA within an 
acquisition strategy and the contracting process. Since the CANES program is currently 
developing and revising its acquisition strategy and contracting process, it would provide 


a case example in which the graduate student could develop his or her thesis. 
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4. Assess Effectiveness of SOA Implementation 


This thesis discussed how the DoD’s requirements established for utilization of a 
MOSA approach enables SOA. Although the Navy has not established policies that 
require the use of SOA, it still desires to use SOA. One of the recommendations of this 
thesis was to establish SOA policies within the Navy and DoD. It would be interesting to 
know, without a current policy requiring the use of SOA, how Program Managers (PM) 
and Milestone Decision Authorities (MDA) are implementing SOA into their programs. 
A graduate student could research and develop a thesis that assesses the effectiveness of 
an SOA implementation by comparing it to the current MOSA implementation within the 
DoD. If PMs and MDAs are not concerned about SOA implementation, they may not 
care about the status of utilizing an SOA. The results of this research may support the 
need for the Navy and DoD to establish policies that require the use of SOA similar to 


those policies established for the requirement to use MOSA. 
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